2008/12/21 Garrett Smith dhtmlkitc...@gmail.com
Styling is done in css.
Dynamic styling is currently done with the style property of HTMLElement.
This is currently implemented in DOM2HTML and HTML5, but I once read they're
going to write a separate CSS-Object Model, whose spec is not ready
Ian Hickson schrieb:
Deprecating HTML thus seems like vain effort. (We already tried over the
past few years with XHTML 1.x, and it didn't work.)
I'd say it _did_ work. :-)
Philipp Kempgen
Am Sonntag, den 21.12.2008, 17:54 +0100 schrieb Philipp Kempgen:
Ian Hickson schrieb:
Deprecating HTML thus seems like vain effort. (We already tried over the
past few years with XHTML 1.x, and it didn't work.)
I'd say it _did_ work. :-)
I'd say too: The worst abominations have
Please Note: all the following is my personal humble opinion.
As I discovered lately, the main problem of HTML5 is its design oriented to
keep features that are distributed across browsers, that work or that are
simple way to solve big problem. Actually, they are a bunch of different
features
Hi Giovanni,
I haven't read your entire comment, but with your point eight will
break backwards compatibility. As far as I know is HTML5 supposed to
combine old and new. The problem with interfaces is that you can not
simply change them. That's just a fact we have to deal with.
jorgen
On 21/12/08 17:22, Nils Dagsson Moskopp wrote:
Am Sonntag, den 21.12.2008, 17:54 +0100 schrieb Philipp Kempgen:
Ian Hickson schrieb:
Deprecating HTML thus seems like vain effort. (We already tried over the
past few years with XHTML 1.x, and it didn't work.)
I'd say it _did_ work. :-)
I'd
On Sun, Dec 21, 2008 at 10:12 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
Please Note: all the following is my personal humble opinion.
parser is involved), events are far better handled by DOM3Events, styling is
included by CSSOM
Styling is done in css.
I don't have time to go
2008/12/17 Ian Hickson i...@hixie.ch
This doesn't cost any time in HTML either, since the tokeniser doesn't
need to worry about what tags have end tags, the tree construction side
just drops unexpected end tags on the floor.
I don't think authors expect tags to disappear.
don't check for
Giovanni Campagna wrote:
2008/12/17 Ian Hickson i...@hixie.ch
This doesn't cost any time in HTML either, since the tokeniser doesn't
need to worry about what tags have end tags, the tree construction side
just drops unexpected end tags on the floor.
I don't think authors expect
2008/12/18 Benjamin Hawkes-Lewis bhawkesle...@googlemail.com
Perhaps (got any actual evidence about author expectations in this case?),
but that's not a problem for tokenizer performance. You're shifting the
goalposts.
My comment about tokenizer performance was later. By the way, author
2008/12/16 Ian Hickson i...@hixie.ch
I tried following this thread but I can't find what I would need to change
in the spec to address the feedback so far. If this feedback relates to
requests for the spec, please elaborate on exactly what it is that should
change -- thanks!
I thought later
On Wed, 17 Dec 2008, Giovanni Campagna wrote:
I thought later on this topic and i arrived to conclusion that we cannot
forbid or delete completely the HTML serialization, but there are no
real use cases for this in server generated web pages. Even in case of
user-generated content an
2008/12/17 Ian Hickson i...@hixie.ch
XML is neither more performant nor stricter than XML. The main differences
are that XML has less user-friendly error recovery and supports arbitrary
namespaces. Authors have clearly indicated that this is not compelling.
Deprecating HTML thus seems like
On Wed, 17 Dec 2008, Giovanni Campagna wrote:
I don't write browser code, honestly, but I think that XML parser don't
need to check for attribute types (they're all quoted strings),
XML parsers still have to check for quotes ( vs '), which takes no less
time than HTML's checking for quotes
On Tue, Dec 16, 2008 at 5:14 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
Maybe so-called invalid HTML attributes are not the only solution, but in
my opinion it is a simple way to embed metadata within any element.
Imagine that such markup is then passed to a web application through
Am Dienstag, den 16.12.2008, 14:22 + schrieb Philip Taylor:
On Tue, Dec 16, 2008 at 2:15 PM, Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net wrote:
As I said, invalid input should be rejected in the first place. When I
write a blog post, I usually catch errors like
On Mon, Dec 15, 2008 at 8:36 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You're not Nicholas. We don't know if that is what Nicholas expects
his HTML to do or if he is expecting something else. In absence of an
2008/12/16 Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net
Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna:
(The same behaviour can be achieved also with a @namespace rule,
putting non-standard attributes in an application-specific namespace)
Since
Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna:
(The same behaviour can be achieved also with a @namespace rule,
putting non-standard attributes in an application-specific namespace)
Since data attributes do not exist as of yet, I believe people would use
XML for
Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna:
Browser assume that author knows XML because he's put an application/*
+xml mime type.
On the other hand, this assumption cannot be done for blogger, who
aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs
2008/12/16 Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net
Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna:
Browser assume that author knows XML because he's put an application/*
+xml mime type.
On the other hand, this assumption cannot be done for
Am Dienstag, den 16.12.2008, 15:02 +0100 schrieb Giovanni Campagna:
2) XML serialization is much more difficlut to implement than old
HTML, and, as i said before, in many cases it is not implementable at
all: probably a company which hosts user-generated content such as
blogs or forums won't
Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna:
Maybe so-called invalid HTML attributes are not the only solution,
but in my opinion it is a simple way to embed metadata within any
element.
What metadata are you talking about ? Microformats already exist.
Personally I
2008/12/16 Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net
Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna:
Maybe so-called invalid HTML attributes are not the only solution,
but in my opinion it is a simple way to embed metadata within any
element.
Maybe so-called invalid HTML attributes are not the only solution, but in
my opinion it is a simple way to embed metadata within any element.
Imagine that such markup is then passed to a web application through XHR. In
that case scripts aren't parsed and executed. In this case you have three
ways
I tried following this thread but I can't find what I would need to change
in the spec to address the feedback so far. If this feedback relates to
requests for the spec, please elaborate on exactly what it is that should
change -- thanks!
--
Ian Hickson U+1047E
On Sat, Dec 13, 2008 at 1:40 AM, Garrett Smith dhtmlkitc...@gmail.com wrote:
On Thu, Feb 28, 2008 at 10:31 AM, h...@nczonline.net wrote:
We then, as developers, could use that attribute as we see fit and
the document would still validate (for people who care about such
things).
Are people
On Mon, Dec 15, 2008 at 6:32 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Sat, Dec 13, 2008 at 1:40 AM, Garrett Smith dhtmlkitc...@gmail.com
wrote:
On Thu, Feb 28, 2008 at 10:31 AM, h...@nczonline.net wrote:
We then, as developers, could use that attribute as we see fit and
the
You're not Nicholas. We don't know if that is what Nicholas expects
his HTML to do or if he is expecting something else. In absence of an
example, I can't do much more than guess. I cannot expect your
assumptions to be correct.
Well, of course, but you sent the message to the entire group, so
On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You're not Nicholas. We don't know if that is what Nicholas expects
his HTML to do or if he is expecting something else. In absence of an
example, I can't do much more than guess. I cannot expect your
assumptions to be
On Mon, Dec 15, 2008 at 6:36 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Valid HTML can have a clear and expected outcome. If something is done
according to standard, it can be expected that that something will
On Thu, Feb 28, 2008 at 10:31 AM, h...@nczonline.net wrote:
We then, as developers, could use that attribute as we see fit and
the document would still validate (for people who care about such
things).
-
Are people who care about things are the
(Not all of this e-mail is covered in this reply. It's possible that I
will reply to the same points in this e-mail multiple times, for which I
apologise in advance.)
On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote:
* I'm not sure what the section/ element offers over the div/
element. I
On Sat, 1 Mar 2008, Nicholas C. Zakas wrote:
As there is also another thread going on about section/, I don't want
to repeat all of my comments here, but suffice to say that I don't see
why I'd ever use section/ when I get implicit sections by using hn/
elements. Writers are used to
On Sat, 8 Mar 2008, Nicholas C. Zakas wrote:
From: Shannon [EMAIL PROTECTED]
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:
Perhaps it would better be named callout/?
Aside is customary in dialogue annotations, I have never seen any
callout.
Call it
Ian Hickson wrote:
On Sat, 8 Mar 2008, Nicholas C. Zakas wrote:
From: Shannon [EMAIL PROTECTED]
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:
Perhaps it would better be named callout/?
Aside is customary in dialogue annotations, I have never
Ernest Cline wrote:
The only synonym of dialog that is anywhere near as general seems to be discourse/.
And I accidentally replied off list:
Discourse is too general.
In philosophy and theology a discourse can mean teaching, as in
Levinas' discourse about 'the other' has made alterity a
Tab Atkins Jr. wrote:
My personal favorite alternate suggestion so far has
been cl.
Yes, I also quite like the analogy with dl/ul/ol. But it may
be confusing when using dt and dd as child elements (as in
the current spec for dialog):
cl
dt
dd
...
/cl
That could be resolved by
-Original Message-
From: Mike Wilson [EMAIL PROTECTED]
Sent: May 15, 2008 8:02 AM
To: 'WHATWG' [EMAIL PROTECTED]
Subject: Re: [whatwg] Thoughts on HTML 5 - dialog
Yes, I also quite like the analogy with dl/ul/ol. But it may
be confusing when using dt and dd as child elements
On Thu, May 15, 2008 at 6:20 PM, Ernest Cline [EMAIL PROTECTED]
wrote:
-Original Message-
From: Mike Wilson [EMAIL PROTECTED]
Sent: May 15, 2008 8:02 AM
To: 'WHATWG' [EMAIL PROTECTED]
Subject: Re: [whatwg] Thoughts on HTML 5 - dialog
Yes, I also quite like the analogy with dl/ul
Zachary Carter wrote:
FWIW, in my first encounter with HTML5 dialog I assumed it meant a
dialog box.
Yes, I assumed the same thing. I think it would be better to not use
such an overloaded term for the stated purpose.
The spec itself uses dialog in both meanings:
3.4.6 ... tabbed dialogs
On Wed, 14 May 2008, Mike Wilson wrote:
Yes, I assumed the same thing. I think it would be better to not use
such an overloaded term for the stated purpose.
I agree in principle, but the alternatives, e.g.:
so my first recommendation would be to go for conversation and live
with its
Ian Hickson wrote:
On Tue, 13 May 2008, Ernest Cline wrote:
I agree that dialog isn't perfect and could be (and has been) confused
with dialog boxes, but I'm not convinced it's not the best name for the
job anyway.
The other possibility is dialogue/ since the computing uses that cause
Karl Dubost writes:
Le 14 mai 2008 à 07:09, Ian Hickson a écrit :
That [talk is] probably the best suggestion so far, but I'm still
not convinced it's really much better than dialog . I think it has
at least as many other interpretations (e.g. what we call a talk
over here is really a
On Wed, May 14, 2008 at 3:36 AM, Mikko Rantalainen
[EMAIL PROTECTED] wrote:
If dialog is used instead of dialogue then it should be designed in
a such way that it can be used for dialog box in addition to dialogue
(e.g. chat) in the future.
I severely doubt this is possible or desirable.
2008/5/13 Ian Hickson [EMAIL PROTECTED]:
On Tue, 13 May 2008, Paweł Stradomski wrote:
[...]
Perhaps talk ? Short and simple, although not exactly equal in meaning
to dialog.
That's probably the best suggestion so far, but I'm still not convinced
it's really much better than dialog. I
converse is more an adjective like opposite to me. Which is even more
awkward.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Smylers
Sent: Wednesday, May 14, 2008 2:12 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Thoughts on HTML 5
Karl
PROTECTED] On Behalf Of Smylers
Sent: Wednesday, May 14, 2008 2:16 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Thoughts on HTML 5
Krzysztof Żelechowski writes:
I recommend transcript because it refers to a conversation that has
been put down
However many things in webpages are things
Ian Hickson wrote:
On Tue, 13 May 2008, Zachary Carter wrote:
FWIW, in my first encounter with HTML5 dialog I assumed it meant a
dialog box. This might be due to my experience with the dialog element
in XUL[1], which is used for that. Also, dialog boxes are generally more
common from my
On Wed, May 14, 2008 at 11:37 AM, fantasai
[EMAIL PROTECTED] wrote:
Ian Hickson wrote:
On Tue, 13 May 2008, Zachary Carter wrote:
FWIW, in my first encounter with HTML5 dialog I assumed it meant a
dialog box. This might be due to my experience with the dialog element in
XUL[1], which is used
My personal favorite alternate suggestion so far has been cl.
throat-warbler-mangrove, anyone? Of course it's not pronounced that way.
- Charles
On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote:
I've just finished taking a look at the working draft of HTML 5 and
thought I'd share my thoughts. Clearly, HTML 5 is meant as an evolution
of HTML 4, which has both its good and bad points. Accordingly, there
are both good and bad parts of the
W liście Ian Hickson z dnia wtorek 13 maja 2008:
* I understand the concept of the dialog/ element but it's named
completely wrong. The point is to markup a conversation between two or
more parties. The problem is that the word dialog, when in used in
user interfaces, refers to small
-Original Message-
From: Ian Hickson [EMAIL PROTECTED]
Sent: May 13, 2008 6:09 PM
To: Paweł Stradomski [EMAIL PROTECTED]
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Thoughts on HTML 5
On Tue, 13 May 2008, Paweł Stradomski wrote:
W liście Ian Hickson z dnia wtorek 13 maja 2008
On Tue, 13 May 2008, Ernest Cline wrote:
The only synonym of dialog that is anywhere near as general seems to be
discourse/.
I dunno, that just sounds so formal.
I agree that dialog isn't perfect and could be (and has been) confused
with dialog boxes, but I'm not convinced it's not the
On Tue, 13 May 2008, Ernest Cline wrote:
I agree that the word discourse is more formal than dialog, but it
does cover both formal and informal speech unlike some other thesaurus
inspired possibilities such as colloquy or chat.
Sure, I'm just reluctanct to use an element name that is too
-Original Message-
From: Ian Hickson [EMAIL PROTECTED]
Sent: May 13, 2008 8:08 PM
Unless we get more evidence that the confusion with dialog boxes is a real
blocker to adoption, I'm going to assume that dialog is our best option.
Is there any reasonable chance an element for a dialog
Le 14 mai 2008 à 07:09, Ian Hickson a écrit :
That's probably the best suggestion so far, but I'm still not
convinced
it's really much better than dialog. I think it has at least as many
other interpretations (e.g. what we call a talk over here is
really a
slide show).
food for thoughts
FWIW, in my first encounter with HTML5 dialog I assumed it meant a
dialog box. This might be due to my experience with the dialog
element in XUL[1], which is used for that. Also, dialog boxes are
generally more common from my browsing experience, so I hadn't
considered the alternative usage at
On Tue, 13 May 2008, Ernest Cline wrote:
Unless we get more evidence that the confusion with dialog boxes is a
real blocker to adoption, I'm going to assume that dialog is our best
option.
Is there any reasonable chance an element for a dialog box might end up
being added to XForms?
]
To: whatwg@lists.whatwg.org
Sent: Monday, March 3, 2008 3:40:15 PM
Subject: Re: [whatwg] Thoughts on HTML 5
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:
Perhaps it would better be named callout/?
Aside is customary in dialogue annotations,
I have never seen
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:
I understand your reasoning for the aside/ element, perhaps this is
another element that is suffering from the wrong name. Most of web
developers have no idea what an aside is let alone when to use one. I
know that acronym/
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze:
Perhaps it would better be named callout/?
Aside is customary in dialogue annotations,
I have never seen any callout.
Chris
Call it note. It may sound crude but it's hard to mistake its meaning.
Shannon
[EMAIL PROTECTED] writes:
I had posted this on my personal blog:
http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested
I join the mailing list to continue the discussion, so here it is:
Hi there Nicholas. Welcome to the list, and thanks for your comments.
I'll try to explain
@lists.whatwg.org
Sent: Friday, February 29, 2008 12:02:24 AM
Subject: Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] writes:
I had posted this on my personal blog:
http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested
I join the mailing list to continue the discussion, so here it is:
Hi
I had posted this on my personal blog:
http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested I join
the mailing list to continue the discussion, so here it is:
I've just finished taking a look at the working draft of HTML 5 and thought I'd
[EMAIL PROTECTED] wrote:
Lachlan had commented that irrelevant could be changed dynamically to
indicate parts of an application that may be relevant only during particular
points in time. I don't see how this is any different from hiding content
that isn't necessary.
Presumably a non-visual UA
Screen readers currently ignore elements with styles of display:none and
visibility:hidden. In order to hide elements from the screen but allow screen
readers to see them, we typically use tricks such as text-indent:-1 and
such.
I would like something to indicate that text should not be
[EMAIL PROTECTED] wrote (with snippage):
* I understand the concept of the dialog/ element but it's named completely wrong. The point
is to markup a conversation between two or more parties. The problem is that the word dialog,
when in used in user interfaces, refers to small windows
Yes, I believe the dialog/ element is supposed to be a disambiguation of the
dl/ element, which has previously been used for both conversations and
definition lists. It makes sense to have separate ones since there's no way to
tell what a dl/ represents now. That being said, I still feel the
70 matches
Mail list logo
