Re: [whatwg] additional empty elements
On Tue, 1 May 2007, Brenton Strine wrote:
>
> Say, for example, you have a website which has sections of content that
> are indented variously. It would be easy to accomplish the different
> styles using classes:
>
> This text isn't indented at all!
> This text is indented a little.
> Lots of indentation.
> No indentation here!
In general you should try to avoid using markup like this, which is tied
to the presentation, and instead use markup that describes the meaning of
the document, and have stylesheets keyed to that.
> However, if I then wanted to add additional special styling to the first
> and third div, (e.g.. a border and background color) it is less
> graceful. I could add style attributes, but that would be wasteful if I
> want to do this on a large scale. Multiple classes would be confusing.
I don't see why multiple classes would be confusing.
> A nice solution would be the addition of a few div tags. (e.g. ,
> , and .) Then you could do something like this:
>
>
> div1 {text-indent:0px;}
> div2 {text-indent:10px;}
> div3 {text-indent:20px;}
>
>
> Then:
>
> This text isn't indented at all!
> This text is indented a little.
> Lots of indentation.
> No indentation here!
>
> This is much more human-readable, and the addition of additional styles
> is now elegant and easy with the use of classes.
>
> This text isn't indented at all!
> This text is indented a little.
> Lots of indentation.
> No indentation here!
I'm not sure I agree that this is more elegant.
> I also think that it would simply be easier to write code if there were
> a few extra non-semantic empty tags. HTML5 needs improvements that will
> make people want to use it. Making it easier to code than HTML 4 will
> ensure a quicker and wider acceptance.
The goal isn't wide acceptance, the goal is a higher quality language.
> I am okay with the unimaginative numbering of the extra elements, as it
> would make it easy to have a lot of new elements. However, there are
> countless possibilities: , , , ,
> , , , , etc...
Well, we have amd now, for sections and figures
respectively.
> Are there other people who have found themselves wishing for another
> or -like tag?
Apparently not. :-)
On Tue, 1 May 2007, Alexey Feldgendler wrote:
>
> HTML is a language for markup meaningful by itself, not just as a hook
> for CSS. doesn't mean anything.
Indeed.
On Tue, 1 May 2007, Jon Barnett wrote:
>
> If you're marking up stuff as a tree, the markup should probably look like a
> tree:
> First group
> Second Group
> Third Group
>
>
>
> if what you want it a tree, that structure is better, so the CSS would
> simply say:
> #tree, #tree div { margin-left: 5em; }
>
> If you want to style each level differently, that's still easy to do without
> making up class names:
> #tree { background: blue; }
> #tree > div { background: green; }
> #tree > div > div { background: yellow; }
Indeed. One could also use nested s for a tree.
On Tue, 1 May 2007, Brenton Strine wrote:
>
> That doesn't seem very practical to me. If all HTML tags imply some
> meaning, then you are advocating the elimination of presentation, not
> it's separation. If there weren't any CSS hooks, wouldn't people just
> (incorrectly) use other tags, like ? I think that CSS and HTML are
> unbreakably connected.
You can hook CSS to the meaning, it doesn't have to be an explicit hook.
For example, you can style your headings:
h1 { color: blue; }
...and the first paragraph after a heading:
h1 + p { text-indent: 2em; }
...and so on.
On Tue, 1 May 2007, Dan Dorman wrote:
>
> An HTML document ought to make semantic sense, without regard to
> presentational information. The very definition of the separation of
> presentation from content is that the content should be authored without
> regard to how it will appear. That's not to say presentation is being
> eliminated, however; presentation simply should not be a consideration
> in how the content is authored. Ideally, anyway.
Indeed.
> Indeed, one could say CSS is fundamentally dependent on HTML; the
> reverse is not true. Imagine a new technology came along to make HTML
> pretty: wouldn't it be nice if you didn't have to rewrite the HTML to
> service this new technology?
Indeed,
> As to folks using incorrect tags, well, what you're proposing isn't
> going to fix that.
Sadly true.
> I think the supposition that multiple class names are confusing is
> flawed. What's wrong with saying
> (besides the fact that you'd want more useful, informative class names
> than "redtext" and "indentmore")? By looking at it, someone could
> readily tell it's got the properties of both "redtext" and "indentmore".
> In my estimation, being able to combine classes is one of the more
> powerful aspects of CSS.
I agree (modulo those class names being poor choices).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+
Re: [whatwg] additional empty elements
On 1 May 2007, at 20:21, Brenton Strine wrote:
However, if I then wanted to add additional special
styling to the first and third div, (e.g.. a border and
background color) it is less graceful. I could add style
attributes, but that would be wasteful if I want to do
this on a large scale. Multiple classes would be
confusing.
A nice solution would be the addition of a few div tags.
(e.g. , , and .) Then you could
do something like this:
div1 {text-indent:0px;}
div2 {text-indent:10px;}
div3 {text-indent:20px;}
Why not:
.first {
color: red;
}
.first + div {
text-indent: 10px;
}
.first + div + div {
text-indent: 20px;
color: blue;
}
Indent 0
Indent 1
Indent 2
Indent 0
Indent 1
Indent 2
Re: [whatwg] additional empty elements
On 5/1/07, Brenton Strine <[EMAIL PROTECTED]> wrote: If all HTML tags imply some meaning, then you are advocating the elimination of presentation, not it's separation. An HTML document ought to make semantic sense, without regard to presentational information. The very definition of the separation of presentation from content is that the content should be authored without regard to how it will appear. That's not to say presentation is being eliminated, however; presentation simply should not be a consideration in how the content is authored. Ideally, anyway. If there weren't any CSS hooks, wouldn't people just (incorrectly) use other tags, like ? I think that CSS and HTML are unbreakably connected. Indeed, one could say CSS is fundamentally dependent on HTML; the reverse is not true. Imagine a new technology came along to make HTML pretty: wouldn't it be nice if you didn't have to rewrite the HTML to service this new technology? As to folks using incorrect tags, well, what you're proposing isn't going to fix that. I think the supposition that multiple class names are confusing is flawed. What's wrong with saying (besides the fact that you'd want more useful, informative class names than "redtext" and "indentmore")? By looking at it, someone could readily tell it's got the properties of both "redtext" and "indentmore". In my estimation, being able to combine classes is one of the more powerful aspects of CSS. Dan Dorman
Re: [whatwg] additional empty elements
> HTML is a language for markup meaningful by itself, not just as a hook for CSS. > doesn't mean anything. That doesn't seem very practical to me. If all HTML tags imply some meaning, then you are advocating the elimination of presentation, not it's separation. If there weren't any CSS hooks, wouldn't people just (incorrectly) use other tags, like ? I think that CSS and HTML are unbreakably connected. Brenton
Re: [whatwg] additional empty elements
If you're marking up stuff as a tree, the markup should probably look like a
tree:
First group
Second Group
Third Group
if what you want it a tree, that structure is better, so the CSS would
simply say:
#tree, #tree div { margin-left: 5em; }
If you want to style each level differently, that's still easy to do without
making up class names:
#tree { background: blue; }
#tree > div { background: green; }
#tree > div > div { background: yellow; }
Child selectors are not supported by IE6, but I believe they are by IE7 and
every other browser.
Re: [whatwg] additional empty elements
On Tue, 01 May 2007 21:21:20 +0200, Brenton Strine <[EMAIL PROTECTED]> wrote: A nice solution would be the addition of a few div tags. (e.g. , , and .) Then you could do something like this: HTML is a language for markup meaningful by itself, not just as a hook for CSS. doesn't mean anything. I am okay with the unimaginative numbering of the extra elements, as it would make it easy to have a lot of new elements. However, there are countless possibilities: , , , , , , , , etc... This is something that WHATWG is already doing (, etc), basing on the popularity of certain classnames found in the wild. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
[whatwg] additional empty elements
I would like to know what other people think about
creating more empty elements in HTML5.
Say, for example, you have a website which has sections
of content that are indented variously. It would be easy
to accomplish the different styles using classes:
This text isn't indented at
all!
This text is indented a
little.
Lots of
indentation.
No indentation here!
However, if I then wanted to add additional special
styling to the first and third div, (e.g.. a border and
background color) it is less graceful. I could add style
attributes, but that would be wasteful if I want to do
this on a large scale. Multiple classes would be
confusing.
A nice solution would be the addition of a few div tags.
(e.g. , , and .) Then you could
do something like this:
div1 {text-indent:0px;}
div2 {text-indent:10px;}
div3 {text-indent:20px;}
Then:
This text isn't indented at all!
This text is indented a little.
Lots of indentation.
No indentation here!
This is much more human-readable, and the addition of
additional styles is now elegant and easy with the use of
classes.
This text isn't indented at
all!
This text is indented a little.
Lots of
indentation.
No indentation here!
I also think that it would simply be easier to write
code if there were a few extra non-semantic empty tags.
HTML5 needs improvements that will make people want to
use it. Making it easier to code than HTML 4 will ensure
a quicker and wider acceptance.
I am okay with the unimaginative numbering of the extra
elements, as it would make it easy to have a lot of new
elements. However, there are countless possibilities:
, , , , ,
, , , etc...
Are there other people who have found themselves wishing
for another or -like tag?
Brenton Strine
