SitePoint Sponsor

User Tag List

Page 5 of 17 FirstFirst 12345678915 ... LastLast
Results 101 to 125 of 402
  1. #101
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    but why?

    iframe should have been dumped, yes, but its purpose has been redefined somewhat, and it can be useful in certain cases, so i don't see that as a reason to write off the whole language.

  2. #102
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Don't get me wrong, HTML5 is better than the current HTML spec. But the XHTML spec... it is MUCH better.

    However, I personally think one spec should be chosen and get this mess over and done with. I could get used to html5, but I dont want to be getting used to both... I have the feeling IE will be saying the same thing.

    I'd personally vote for XHTML though. It's a big leap in the right direction, whereas HTML seems to be a small step diagonally.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  3. #103
    SitePoint Zealot Amenthes's Avatar
    Join Date
    Oct 2006
    Location
    Bucharest, Romania
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    One word? iFrame. ... well technically that was not deprecated before HTML5 began construction but it should have been dumptrucked a while ago.
    You know every Rich Text Editor out there is implemented on top of an iframe?
    Everything in this life has bad and good uses. If there are cases where iframes
    should not be used that's an entirely different situation.

    Also, in software development is often easier/better to restructure than rebuild
    from scratch. Backwards compatibility, which HTML5 struggles to obtain, is very
    important. You can't just say "stop" to all the browsers on this plant, in order to
    reinstall a new one (which probably hasn't been properly tested) and then,
    "start" the new browsing era. Unfortunately things are harder (for us).

    XHTML2 may be better, but it's a utopia in my opinion. In the meantime we have
    information to deliver.

    Quote Originally Posted by arkinstall View Post
    However, I personally think one spec should be chosen and get this mess over and done with. I could get used to html5, but I dont want to be getting used to both... I have the feeling IE will be saying the same thing.
    And that's the way it is, although not officially. I mean, every major browser out
    there concentrates its efforts towards HTML5. Isn't that a really good thing?
    I'm under construction | http://igstan.ro/

  4. #104
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I mean, every major browser out there concentrates its efforts towards HTML5. Isn't that a really good thing?
    Just because something is easier doesn't mean it's better.

    In fact, XHTML looks easier to accomplish browser-wise.

    It doesn't require many new elements, and it encourages good coding - both make rendering easier.

    Besides, serving a HTML4 page will still be correct for a good while.

    Sometimes it takes more than just moderate changes now and then to make a good overall change. This is a spec change and a chance to fix the many sloppy practises. If they do so with BIG changes, it's going to hit the web headlines and people are going to get their acts into gear.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  5. #105
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Stormrider, it was just one example of the many down fallings of HTML5. IFrames in every respect are bad, they are damaging to both usability and accessibility and are quite frankly unnecessary. If you wanted to produce some self contained content which is wrapped with scrollbars then it would make more sense to use a divider with overflow and a fixed height and width. It would achieve the same visual and browsing effect but would maintain accessibility with more grace then the current framed alternative.

    Amenthes, just because something is being used on a large scale does not make it a good idea. Also I should point out that progressive enhancement is a much better approach then backward compatibility, there are many dangers with backward compatibility as rather than give browsers what they can handle you are trying to fix a leaking pipe with some duct tape. What you have said about saying stop to all the browsers is pretty much redundant, everyone knows that browsers gain support for technologies in a granular fashion over time, you are making it seem like if we wanted to support a new web standard we would need to automatically block every other browser from visiting the website and this is just not the case.

  6. #106
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,869
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    iframes were replaced by the object tag a long time ago. If browsers supported the object tag properly then iframe would be long dead and buried. A number of other tags have been introduced into HTML5 also to make up for the fact that some browsers don't support the object tag properly.

    If browsers don't properly support the standards that are there then what makes anyone think that by changing the standards that those browsers are going to support it any better.

    Everything that has been deprecated was deprecated for a reason and those reasons still exist. Those developing the next version should therefore obey the deprecated instruction and DROP support for the deprecated elements from the next standard since it has already been approved that they should do so. That iframe should not be a part of HTML 5 was approved many years ago whereas the rest of the HTML 5 standard is still at an early draft stage.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  7. #107
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    If you wanted to produce some self contained content which is wrapped with scrollbars then it would make more sense to use a divider with overflow and a fixed height and width. It would achieve the same visual and browsing effect but would maintain accessibility with more grace then the current framed alternative.
    An overflow box is not a frame. A frame is a completely different document inside another document. This other document has its own URL, it's own server headers, its own styles and scripts. The few times I've been forced to allow an iFrame is precisely those times when <object> would not work properly (esp a... um, certain browser)... like one bank calling the form page of another bank. Filling in the other form, the user is on our page but interacting with the other bank's server. <object> should be able to do this, and sometimes it can. Depends on what you're doing with it.

    Granted if I could just rewrite the whole page there would just be a link to the other bank's form page, done.

    Also I should point out that progressive enhancement is a much better approach then backward compatibility, there are many dangers with backward compatibility as rather than give browsers what they can handle you are trying to fix a leaking pipe with some duct tape.
    Agreed, in that backwards compatibility can cause issues in progress... for instance, why IE7 didn't go as far as it could have, retaining Haslayout and other things partially to be able to act like IE6 and be able to go into the same Quirks mode. IE8 was a tough decision for MS, to break off and redo large chunks of it (esp removing Haslayout... why they didn't just go ahead and make a whole new rendering engine, I dunno).

    I too would rather browsers just implemented <object> completely than retaining a crippled iFrame. I wouldn't say iFrame is always less accessible-- <object> can be inaccessible too if it's calling a separate document, depends how you write it.

  8. #108
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Everything that has been deprecated was deprecated for a reason and those reasons still exist. Those developing the next version should therefore obey the deprecated instruction and DROP support for the deprecated elements from the next standard since it has already been approved that they should do so. That iframe should not be a part of HTML 5 was approved many years ago whereas the rest of the HTML 5 standard is still at an early draft stage.
    But which deprecated elements are being bought back? <font> is the only one I can see mention of, and that is only for CMS's, which makes sense to me. The way the web is used has changed a lot since those tags were deprecated, its silly to shoot yourself in the foot by saying you can never bring them back.

  9. #109
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Stormrider View Post
    But which deprecated elements are being bought back? <font> is the only one I can see mention of, and that is only for CMS's, which makes sense to me. The way the web is used has changed a lot since those tags were deprecated, its silly to shoot yourself in the foot by saying you can never bring them back.
    And it seems rather redundant to proclaim that tags such as FONT can have any place in semantic mark-up when the clear definition of that tag is for presentation purposes only. What would you like next? To bring back <center>, <blink> and <color> ?

  10. #110
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    <font> is not allowed in HTML5.
    Simon Pieters

  11. #111
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    And it seems rather redundant to proclaim that tags such as FONT can have any place in semantic mark-up when the clear definition of that tag is for presentation purposes only. What would you like next? To bring back <center>, <blink> and <color> ?
    I didn't say it was semantic, I said it makes sense for a WYSIWYG editor, the whole purpose of which is to define the presentation of text, after all. Likewise with b and i, which aren't semantic, but are used to replicate typographic conventions.

    Simon: That's good to know, I had heard it was being allowed again for WYSIWYG editors. So are there actually an tags being un-deprecated at all then?

  12. #112
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, <iframe> and <menu>. The latter is really a new element with an old name; it's intended for context menus and toolbars.

    <iframe> also has new features that people have been requesting, e.g. here http://friendlybit.com/html/html-includes/
    Simon Pieters

  13. #113
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Stormrider View Post
    I didn't say it was semantic, I said it makes sense for a WYSIWYG editor
    Which pretty much proves the point that WYSIWYG editors are senseless.

  14. #114
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    So what would use suggest using for eg, a CMS instead of a WYSIWYG editor?

    Simon: The menu element as you say has a different purpose now really. So it's only iframe, and even that almost has a different purpose / new uses at least. There aren't really any elements being brought back with their original purpose.

  15. #115
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,892
    Mentioned
    123 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Stormrider View Post
    So what would use suggest using for eg, a CMS instead of a WYSIWYG editor?
    <span style="..."> would seem to be the most appropriate if the editor isn't capable of working with <span class="...">

  16. #116
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    How is an unsemantic style="" attribute any better than a font attribute? Why is using <span class=""> any more semantic? That conveys no semantic information at all. How would the WYSIWYG editor decide an appropriate class name? It seems using <font> makes it clearer than trying to second guess what is meant and using neutrally semantic markup.

    <font> could be considered more semantic anyway, it means 'the person wants this text displayed in this font'.

  17. #117
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    In my opinion it would be better to provide no semantic meaning then incorrect semantic meaning for the context of the website in general. Two wrongs to certainly not make a right and just because it makes sense for the WYSIWYG editor does not mean it is correct in the broader scheme of things. But then again I am a web standards nut.

    PS: if you want to apply explicit style to a cluster of text within say a paragraph such as alternative fonts, using the SPAN tag is actually the most semantically correct thing you can do. Changing style information for a font does not alter the semantic purpose of the parent tag they are held within, and if there is meant to be semantic meaning behind a style related change (such as emphasising some text) then why not use the appropriate EM tag?

  18. #118
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Why would using a font tag for this purpose provide incorrect semantic meaning?

    With a WYSIWYG editor, if someone chooses italicised text, you have no idea if they mean italics, or emphasised, and there is no way for the editor to tell. Using <em> would be incorrect in this circumstance because you cannot be sure they meant to emphasise the text. Using <i> gives no semantic meaning, but has the same effect. Why is using <span> any better than using <i>? Neither tag conveys any semantics, but the <i> tag is perfect for the situation - the user wanted italicised text, without knowing why, the best thing an editor can do is use the <i> tag.

    Don't get me started on editors (or even authors) who wholesale replace <b> with <strong> and <i> with <em>, without any thought given to why the text was bold or italicised, and thinking that makes them more 'semantic' and 'accessible'...

  19. #119
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Stormrider View Post
    <font> could be considered more semantic anyway, it means 'the person wants this text displayed in this font'.
    <sarcasm> Wow so now using font tags is semantic? I knew in the English language that it was appropriate to emphasise, quote and give strength behind key words in a sentence structure, but apparently Stormrider says that we should “font” words within our paragraphs, so from now on whenever someone changes typeface in their posts I want you all to yell FONT VERDANA so that people know the typeface has altered... oh wait, changing typefaces does not require meaning behind it, and nor do we need to declare it in the English language... why? Because it is blindingly obvious when a font is changed and it provides no value to the meaning of the text held within. </sarcasm>

  20. #120
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    WYSIWYG editors are maybe doing the wrong thing then.

    At the moment, they give the user control of what the text LOOKS LIKE. That isn't the job of HTML, so that needs a rethink.

    Instead of giving the user direct control of how to show things, how about a more out-of-the-box idea. Don't let them chose 'bold' or 'italic', but instead let them choose what the text IS. Why not have a button saying 'emphasize text' etc, and let the page's STYLE tell the page what it will look like.

    That way, a CMS-created page can be completely changed by editing the CSS file.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  21. #121
    SitePoint Wizard silver trophybronze trophy
    Join Date
    Jul 2008
    Location
    New York, NY
    Posts
    1,432
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The font element should not be supported in HTML 5, but is allowed when inserted by a WYSIWIG editor.
    If only....
    <font size="3" presentational="true"></font>

    *[presentational="true"] {
    border: 10px solid black;
    }

    Honestly presentational tags should be avoided at all costs. If there is no tag appropriate for the job then either span or div should be used... In the context of an inline element, span is most appropriate...

    The WYSIWIG should output <span class="presentational-b">Bolded Text</span> when bold is selected....

    U - <span class="presentational-u">Underlined Text</span>
    .. and so fourth...

  22. #122
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    <sarcasm> Wow so now using font tags is semantic? I knew in the English language that it was appropriate to emphasise, quote and give strength behind key words in a sentence structure, but apparently Stormrider says that we should “font” words within our paragraphs, so from now on whenever someone changes typeface in their posts I want you all to yell FONT VERDANA so that people know the typeface has altered... oh wait, changing typefaces does not require meaning behind it, and nor do we need to declare it in the English language... why? Because it is blindingly obvious when a font is changed and it provides no value to the meaning of the text held within. </sarcasm>
    Blindingly obvious to sighted people...

    Quote Originally Posted by arkinstall View Post
    WYSIWYG editors are maybe doing the wrong thing then.

    At the moment, they give the user control of what the text LOOKS LIKE. That isn't the job of HTML, so that needs a rethink.

    Instead of giving the user direct control of how to show things, how about a more out-of-the-box idea. Don't let them chose 'bold' or 'italic', but instead let them choose what the text IS. Why not have a button saying 'emphasize text' etc, and let the page's STYLE tell the page what it will look like.

    That way, a CMS-created page can be completely changed by editing the CSS file.
    You and I know full well that wouldn't work. The vast majority of users that WYSIWYG editors are targeted at wouldn't be able to cope with this, they wouldn't be able to satisfactorily split up a piece of text into semantic blocks, this is just a recipe for disaster.

    Quote Originally Posted by cooper.semantics View Post
    Honestly presentational tags should be avoided at all costs. If there is no tag appropriate for the job then either span or div should be used... In the context of an inline element, span is most appropriate...

    The WYSIWIG should output <span class="presentational-b">Bolded Text</span> when bold is selected...
    But why is that semantic? I see <font> as being the same as <b> or <i> - those tags can be used when the typography requires 'bold' rather than just 'strong emphasis' - those have different meanings. I fail to see why presentational tags can't have semantics

    Everyone here seems to be so dead set against the idea of it that they aren't thinking clearly and are reacting against it immediately without thinking.

    I'm not saying the font tag was ever good, it has been abused in the past, but for a WYSIWYG editor, using this tag makes perfect sense I think. If a designer was to change the font in the css, it would change for all the WYSIWYG posts - and WYS is no longer WYG, because it has changed. Using font enables the editor to 'freeze' the style of that section of CMS driven content, and guarantee that what they saw is indeed now what they got. If a page author doesn't want to give this level of control to a user, then it's easy enough to turn off the font selector in an editor, or whatever else they want to turn off, but why deny them that option in the first place?

    So the reasons for everyone hating HTML 5 are so far 'they bought back 2 tags that used to be abused but have now had their meaning redefined'?

  23. #123
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Stormrider View Post
    Blindingly obvious to sighted people...
    But how is a change in font important to anyone? let alone a visually impaired viewer. A change in font does not have any semantic reasoning for it unless that font change is meant to represent something such as giving emphasis to a particular cluster of text. A change in style itself is not a rule in the English language which requires definition and explanation. The simplest answer would be to use a span with a purpose built Microformat to relay explicitly styled information that has meaning beyond the specifications. That is, if you wanting to let the user / search engine / know you are making the pretty font look bigger so it uses more screen space (which in my opinion has nothing to-do with the meaning of the content, but whatever).

    Quote Originally Posted by Stormrider View Post
    You and I know full well that wouldn't work. The vast majority of users that WYSIWYG editors are targeted at wouldn't be able to cope with this, they wouldn't be able to satisfactorily split up a piece of text into semantic blocks, this is just a recipe for disaster.
    Only the problem is that if you and me can manage to do it with little trouble, an editor which just inserts a block of code upon hitting a button should not have any harder a job. And for the record, I used to be a software developer and the idea of being able to change the way code is implemented would be extremely easy to achieve.

    Quote Originally Posted by Stormrider View Post
    Everyone here seems to be so dead set against the idea of it that they aren't thinking clearly and are reacting against it immediately without thinking.
    That statement is insulting. You are stating that if we do not agree with you that we should immediately be considered biased, ignorant and or unable to partake in cognitive function. Sorry to point it out but perhaps the reason people arent agreeing with you is because you seem to be confused over what constitutes good semantics.

  24. #124
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,194
    Mentioned
    17 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by Stormrider
    You and I know full well that wouldn't work. The vast majority of users that WYSIWYG editors are targeted at wouldn't be able to cope with this, they wouldn't be able to satisfactorily split up a piece of text into semantic blocks, this is just a recipe for disaster.
    I think you hit the problem dead one. The target market cares about visuals not how semantically profound their code is which a normal viewer could care about less. They just care that it works. Those types of editors do provide that in a very visual manor which makes them great for their target market. In many respects these editors would require a form of artificial intelligence to determine the semantic appropriateness of the tags used. I don't see that happening any time soon. It doesn't seem very practical.

  25. #125
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,869
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    So if cluttering up a page with garbage tags is acceptable then why not fillthem with all the conditional comments etc that Microsoft Word will create and use that as the standard for WYSIWYG editors. There are enough good WYSIWGY editors around now that can actually create valid code and the others currently have the incentive to fix their code so that they too validate. Adding garbage code to HTML to allow the code that the poor quality WYSIWYG editors to be considered is a step on the path to accepting Word output as valid.

    As a totally separate question - Why does HTML 5 add a <!DOCTYPE html> tag. Other versions of HTML and XHTML have never had such a weird tag as a part of their syntax. HTML 2 through 4 and XHTML have always started with an SGML definition tag which is a part of SGML and not a part of the (X)HTML language. Is that tag supposed to come after the SGML tag defining the content as XHTML 5 for any sensible person attempting to define the actual SGML doctype on the front of their documents? It certainly isn't a valid SGML tag. Is there even going to be a proper SGML definition of HTML 5 or do we just call it garbage instead of calling it a markup language. SGML has certainly been around for long enough that it doesn't make sense to define any sort of markup language that isn't SGML.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •