W3C home > Mailing lists > Public > www-style@w3.org > April 2008

RE: [cssom-view] small update

From: Mike Wilson <mikewse@hotmail.com>
Date: Mon, 21 Apr 2008 22:56:02 +0200
Message-ID: <BAY116-DAV628C2897ED927A07F3F65A4E10@phx.gbl>
To: "'Www-style'" <www-style@w3.org>
Message-ID: <00ae01c8a3f2$1c0398b0$0a01a8c0@mikedeskxp>

Anne van Kesteren wrote:
>> >> Do you think this section
>> >> http://dev.w3.org/csswg/cssom-view/#background
>> >> is clear enough on that or do you want me to add a sentence saying
>> >> explicitly that it doesn't match current implementations?
>> >
>> > If chosing this path I would like to see comments in each
>> > relevant section, mentioning heritage and compatibility, f ex:
<snip>
> It's no longer relevant in the future. Would you expect HTML5 
> to do the same thing?

I would say that HTML5 is different for two reasons:
- Its predecessors are well defined in previous specs so the reverse-
  engineering step isn't needed (at large that is).
- It will be subject to DOCTYPE switching so its incompatible changes
  will not break old content. [Then again, what everybody is thinking 
  may be that CSSOM should also be subject to DOCTYPE switching, 
  although the spec hints that the described algorithms should be used 
  for all modes. I would definitely think that IE will need to DOCTYPE 
  switch and probably only use CSSOM rules in their new standards mode.]

Also, there actually is a report describing the changes between HTML4
and HTML5 http://www.w3.org/TR/html5-diff/ as you probably know, being 
the editor of it. 

So I would say that HTML5 has exactly the background information in
writing that I think is necessary for making an informed judgement 
about Wise Decisions:
- the previous specs (corresponding to IE reverse-engineering info in
  the cssom case)
- the diff report (corresponding to info about intentional incompatible
  changes in the cssom case)

> > If chosing this path I would like to see comments in each 
> > relevant section, mentioning heritage and compatibility, f ex:
> > 
> > 8.1 The offsetParent, offsetTop, offsetLeft, offsetWidth, and 
> >     offsetHeight attributes
> > ..
> > These attributes were originally implemented as vendor-specific
> > enhancements to Internet Explorer. The algorithms described below
> > are a mix of several browsers' behaviour plus some new behaviour,
> > and are not fully compatible with the Internet Explorer 
> > implementation.
> 
> If someone could do this that would be very cool indeed. I 
> personally have no time to work on this and given experience 
> elsewhere, e.g. HTML 5, I do not think it is strictly necessary.

As I said earlier I think this information is not only cool but 
actually crucial to understanding the suggested algorithms'
implications. You have expressed two reasons why you shouldn't
add this information:
1) Not suitable in spec.
   I think Alan has a good suggestion in that it could be added for
   now and removed later when it is not of interest any longer.
   It would be suitable to use the Note or Issue paragraph styles as 
   used extensively by HTML5.
2) No time to work on this.
   If adding this information as notes to the spec it should just be
   about transferring your personal notes into one or two sentences 
   per feature/section.

[from old mail]
> Do you think this section 
> http://dev.w3.org/csswg/cssom-view/#background is clear enough on 
> that or do you want me to add a sentence saying explicitly that it 
> doesn't match current implementations?

A generic incompatibility disclaimer doesn't tell the reader a lot.
That's why I think it has to be told per feature whether it is
incompatible or not as I'm sure different decisions have been taken 
for different features?
We have mainly been discussing the offset* properties but I think 
your audience has an equally high interest in knowing about any 
incompatibilities for f ex getClientRects() and 
getBoundingClientRect() that also have an IE legacy, or any other 
reverse-engineered feature of the spec.

So please try to make some of this information available in the spec.
I'm sure you can find a suitable way of doing it. 

Best regards
Mike Wilson
Received on Monday, 21 April 2008 20:56:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:05 GMT