4 ms·

Writing W3C spec and smoking crack are not mutually exclusive activities

24 points by dan_sim 17y ago

mkelly 17y ago
I'm not agreeing or disagreeing with the author's point, but I thought there was a push to move away from lots of special-case tags like <q>, <dl>, etc. For such a general-purpose SGML, it seems silly to assume that HTML will have a semantically-meaningful tag for the majority of your semantics. Maybe I'm smoking crack, though. :)
- windsurfer 17y ago
  But they still define them. Either keep them or toss them, but don't just half heartedly try.
ThinkWriteMute 17y ago
I pretty much use div and span with ID and CLASS to achieve what I want.
daleharvey 17y ago
I honestly never understood why html needs to manually specify all these tags, due to the contraints their semantics are as much as lost, just give us some tags with clear and precise semantics list, quote, address, a, input etc, then let us markup the rest with whatever we want.
- jerf 17y ago
  The more clearly you specify the semantics, the less applicable the tag is, by necessity. Personally, I've come around to the idea that semantic HTML is a joke, because "semantics" can only exist in the context of an agreed-upon semantic context and there's absolutely no way to declare One True Semantic Context, handed down from a committee. There's nothing more or less "semantic" about <cite> vs. <div class="cite">; both may be meaningless, or one may be meaningful but not the other, or both may mean subtly different things, all depending on the context they are in. Nor does wrapping something in a non-existant tag <book> magically make it "non-semantic" or "semantic", until a context is (or is not) added. There's no magic in the tag name; it's just a meaningless string by itself. Bear in mind that much of the reason I say that the centralized committee can't hand down the One True Context is that even if they do, it is simply a fact that vast swathes of the web will ignore their dictate, and a world in which only 10% of the uses of the "cite" tag are actually "semantically correct" is a world in which the putative semantics are useless. (And if you say "Well, we'll cut it down to a certain subset, like my personal store of documents.", my response is, yes, yes you will, and that's exactly what I mean by a "semantic context".) (And 10% is probably a gross, orders-of-magnitude overestimate.) Context-free semantics is a contradiction in terms.
  - daleharvey 17y ago
    One true semantic context is of course a pipe dream, theres 2 reasons I would like to be able to define whatever tag I want. 1. My markup is cleaner, <contextmenu> vs <div id="contextmenu">, this has implications on my javascript and css (both in terms of speed and cleanliness) 2. API and "microformats" are trivialised, this is of course also dependant on producing parseable (x)html (another decision I really dont understand) but why on earth is http://api.flickr.com/services/rest/?method=flickr.people.getPublicPhotos&api_key=d6c998c73b6ba60e7b31b83618909afe&user_id=69845378%40N00 http://api.flickr.com/services/rest/?method=flickr.people.ge... different from http://www.flickr.com/photos/daleharvey http://www.flickr.com/photos/daleharvey they really dont need to be
    - jerf 17y ago
      Yes, as a direct consequence of the fact that I don't believe in One True Context, I think the proper solution to HTML 5 is to say "Look, tags can be anything, here's enough CSS to style your arbitrary tags" (which we pretty much have, CSS 3 removed the last browser-only magic by letting you futz with tables), and everything else should be a separate standard. That said, I think this approach even sort of mostly works already, albeit with some pain and some JS hackery required. I just want it in the standard. And if we were doing that, I would ask for some events around tags, so I could in the <head> register a "tag creation" listener for, say, <calendar>, and so when that tag is encountered, use JS to populate it with stuff the browser understands. Alas, I am not the standard maker.
    - blasdel 17y ago
      The Flickr people thought naked RPC via URL query strings was somehow RESTful just because you can use GET. They didn't have a fucking chance of noticing the existence of the Accept header. Microformats are bullshit when you have <link> and HTTP!
  - blasdel 17y ago
    The problem with elements like <cite> is that they don't do anything -- since there's no default style they're just <span> with added wankery. Just because the spec exhorts you to use them a particular way doesn't mean that anyone will do that -- the real world has proven over and over again that unstyled tags are used as if they were classes, and attributes that aren't parsed by user agents from day 0 will have random shit stuffed in them. This isn't be done by ignorant users, but by aspirational Zeldman-reading cargo-cultists, almost always in the name of accessibility (see the saga of longdesc). At least the putatively 'semantic' <em> and <strong> tags have agreed-upon meanings in the real world: they're synonyms for <i> and <b> -- and noone can argue otherwise in a world where every WYSIWYG toolbar has a B button that insets <strong> tags.
jacoblyles 17y ago
I'm hoping this title is literal, as in "smoking crack and being the mayor of DC are not mutually exclusive activities" edit: No, the title is false advertising.

24 points by dan_sim 17y ago

I'm not agreeing or disagreeing with the author's point, but I thought there was a push to move away from lots of special-case tags like <q>, <dl>, etc. For such a general-purpose SGML, it seems silly to assume that HTML will have a semantically-meaningful tag for the majority of your semantics. Maybe I'm smoking crack, though. :)

windsurfer 17y ago
But they still define them. Either keep them or toss them, but don't just half heartedly try.

ThinkWriteMute 17y ago

I pretty much use div and span with ID and CLASS to achieve what I want.

daleharvey 17y ago

I honestly never understood why html needs to manually specify all these tags, due to the contraints their semantics are as much as lost, just give us some tags with clear and precise semantics list, quote, address, a, input etc, then let us markup the rest with whatever we want.

jerf 17y ago
The more clearly you specify the semantics, the less applicable the tag is, by necessity. Personally, I've come around to the idea that semantic HTML is a joke, because "semantics" can only exist in the context of an agreed-upon semantic context and there's absolutely no way to declare One True Semantic Context, handed down from a committee. There's nothing more or less "semantic" about <cite> vs. <div class="cite">; both may be meaningless, or one may be meaningful but not the other, or both may mean subtly different things, all depending on the context they are in. Nor does wrapping something in a non-existant tag <book> magically make it "non-semantic" or "semantic", until a context is (or is not) added. There's no magic in the tag name; it's just a meaningless string by itself. Bear in mind that much of the reason I say that the centralized committee can't hand down the One True Context is that even if they do, it is simply a fact that vast swathes of the web will ignore their dictate, and a world in which only 10% of the uses of the "cite" tag are actually "semantically correct" is a world in which the putative semantics are useless. (And if you say "Well, we'll cut it down to a certain subset, like my personal store of documents.", my response is, yes, yes you will, and that's exactly what I mean by a "semantic context".) (And 10% is probably a gross, orders-of-magnitude overestimate.) Context-free semantics is a contradiction in terms.
- daleharvey 17y ago
  One true semantic context is of course a pipe dream, theres 2 reasons I would like to be able to define whatever tag I want. 1. My markup is cleaner, <contextmenu> vs <div id="contextmenu">, this has implications on my javascript and css (both in terms of speed and cleanliness) 2. API and "microformats" are trivialised, this is of course also dependant on producing parseable (x)html (another decision I really dont understand) but why on earth is http://api.flickr.com/services/rest/?method=flickr.people.getPublicPhotos&api_key=d6c998c73b6ba60e7b31b83618909afe&user_id=69845378%40N00 http://api.flickr.com/services/rest/?method=flickr.people.ge... different from http://www.flickr.com/photos/daleharvey http://www.flickr.com/photos/daleharvey they really dont need to be
  - jerf 17y ago
    Yes, as a direct consequence of the fact that I don't believe in One True Context, I think the proper solution to HTML 5 is to say "Look, tags can be anything, here's enough CSS to style your arbitrary tags" (which we pretty much have, CSS 3 removed the last browser-only magic by letting you futz with tables), and everything else should be a separate standard. That said, I think this approach even sort of mostly works already, albeit with some pain and some JS hackery required. I just want it in the standard. And if we were doing that, I would ask for some events around tags, so I could in the <head> register a "tag creation" listener for, say, <calendar>, and so when that tag is encountered, use JS to populate it with stuff the browser understands. Alas, I am not the standard maker.
  - blasdel 17y ago
    The Flickr people thought naked RPC via URL query strings was somehow RESTful just because you can use GET. They didn't have a fucking chance of noticing the existence of the Accept header. Microformats are bullshit when you have <link> and HTTP!
- blasdel 17y ago
  The problem with elements like <cite> is that they don't do anything -- since there's no default style they're just <span> with added wankery. Just because the spec exhorts you to use them a particular way doesn't mean that anyone will do that -- the real world has proven over and over again that unstyled tags are used as if they were classes, and attributes that aren't parsed by user agents from day 0 will have random shit stuffed in them. This isn't be done by ignorant users, but by aspirational Zeldman-reading cargo-cultists, almost always in the name of accessibility (see the saga of longdesc). At least the putatively 'semantic' <em> and <strong> tags have agreed-upon meanings in the real world: they're synonyms for <i> and <b> -- and noone can argue otherwise in a world where every WYSIWYG toolbar has a B button that insets <strong> tags.

jacoblyles 17y ago

I'm hoping this title is literal, as in "smoking crack and being the mayor of DC are not mutually exclusive activities" edit: No, the title is false advertising.