HTML Weekly Teleconference

 

 

<trackbot> Date: 09 April 2009

<smedero> well, I did scribe recently!

<smedero> heh

<rubys> this is NOT working :-)

ok.

<rubys> scribenick: ChrisWilson

sam: looks around for lachlan

action-115?

<trackbot> ACTION-115 -- Michael(tm) Smith to set up WBS for HTML WG participants to @@ reTPAC 2009 -- due 2009-04-07 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/115

<pimpbot> Title: ACTION-115 - HTML Weekly Tracker (at www.w3.org)

MikeSmith: didn't realize I had that, will need to move date out +1week

<MikeSmith> trackbot, action-115 due next week

<trackbot> ACTION-115 Set up WBS for HTML WG participants to @@ reTPAC 2009 due date now next week

<rubys> ack, julian

<Julian> Regarding ACTION-103: followed up on the mailing list; J. Holsten promised a new draft soonish

action-105?

<trackbot> ACTION-105 -- Sam Ruby to should arrange a meeting between chairs of HTML WG and XHTML2 WG to ensure there is a plan for coordination of vocabularies to avoid incompatibilities. -- due 2009-04-09 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/105

<pimpbot> Title: ACTION-105 - HTML Weekly Tracker (at www.w3.org)

<Julian> on ACTION-103: http://lists.w3.org/Archives/Public/public-html/2009Apr/0088.html

<pimpbot> Title: Re: Registering the about: URI scheme from Joseph A Holsten on 2009-04-03 (public-html@w3.org from April 2009) (at lists.w3.org)

sam: I've met with Steven Pemberton and others at AC; have posted some outcomes from that discussion

<masinter> emails didn't get linked to action item

sam: some idea that some extensibility capabilities would meet a lot of needs.

<MikeSmith> action-105?

<trackbot> ACTION-105 -- Sam Ruby to should arrange a meeting between chairs of HTML WG and XHTML2 WG to ensure there is a plan for coordination of vocabularies to avoid incompatibilities. -- due 2009-04-09 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/105

<pimpbot> Title: ACTION-105 - HTML Weekly Tracker (at www.w3.org)

Larry: would be useful if reports were linked to this action

sam: I'll do that.

dsinger: I'm not confident that putting the two groups together in one room wouldn't cause chaos.

larry: it's not clear to me that the current chaos is any worse than the chaos that would ensue

dsinger: I think it would be - both groups would come to a standstill

<masinter> divergence is destructive

sam: I think dsinger would like to hear confirmation that the XHTML2 group believes in the HTML design principles.
... will take action to confirm that

<masinter> I agree that agreement on design principles is highly desirable

<Zakim> MikeSmith, you wanted to ask Sam whether he's heard feedback about merging HTMLWG+XHTML2WG from anybody other than Steven and IBM colleagues

sam: yes, I did talk to a number of people who were at the AC meeting, including several browser vendors and XHTML2 WG participants.

larry: there were ~20 people in the breakout room.

sam: obviously with the mail I sent yesterday, the discussion is now open to everyone (= the internets)

dsinger: you seem to be making progress, so I'm (hopeful? despite being skeptical?)

julian: sam, where did you send that mail? (shawn answers^^)

larry: i did have a comment - I'd like to distinguish between platform and language features a little better
... plugins are another way platform features get added

<shepazu> [both platform and language features, actually]

larry: it may very well be there are some plugin features that become platform features over time; I don't think the architecture should exclude plugins as a way features get added.

sam, can you repeat that?

sam: is the idea of plugins something that should be factored into the design principles?

larry: most likely
... it isn't addressed in the current design principles, but I think it would be a good thing to add
... your post currently only mentions browsers, but plugins add platform features too

Mike: I don't agree at all that platform features are added via plugins.
... core platform features are not added by third-party plugins.

larry: never?

mike: never, by definition.

doug: what about SVG?

mike: there's an open standard for SVG, it's not
... "added" thru the plugin as a language feature, it's added because there's a standard
... it's not under the control of the plugin whether it's a language feature or not.

<shepazu> [I wonder if FF extensions could be considered a plugin for these purposes... I guess it depends on the extension]

larry: if it's a platform extension, it's okay only after it becomes a recommendation, not before?

doug: take the example of PDF. It could easily be implemented by a browser. Would that be a platform feature [of HTML]?
... that seems like a political not a technical distinction
... not that I'm dissing the open web [ed: yeah right]

<MikeSmith> I guess I don't see what it's useful for us to be trying to define what a "platform feature" is at all

<dsinger> Hm, surely platform features are required browser behavior...there is UA behavior associated

<dsinger> language features are things like tags you put in your document so that search engines index you better

larry: platform/language extensibility is a good idea; I was just saying it seems to be a legitimate way of extending the web

doug: I tend to agree with larry. If you're going to talk about extending the web in terms of features, what's the practical way of saying "plugins are okay"?

larry: if the web platform relies on plugins, breaking plugins would break the web.

<dsinger> there is required browser behavior to enable plugins. the conformance stops at 'invoke the plugin if you have it'

<MikeSmith> what dsinger said.

doug: I don't think anyone wants to break plugins - I like me some Flash games.
... adding new features to enable plugins might put more of a burden on the language, which may or may not be a good thing - at the very least, it's a different thing.

larry: I wasn't suggesting that - just that new CSS, etc. functionality should take into account that plugins shouldn't get broken.

jgraham: notes that there are quite complex issues with plugins and parsing, scripting, etc.

doug: some of these issues are also appropriate when SVG is referenced, just due to browsing context.

larry: I'll raise an issue on this

<Zakim> MikeSmith, you wanted to say let's avoid the problem by not using the term "platform feature" at all

mike: larry and doug seem interested in this, so I would suggest they write up a spec for this.
... maybe we shouldn't be trying to define what a platform feature is at all.

sam: at the AC mtg, there was some idea that the delta between SVG and, say, RDFa should be captured, because they're different (SVG requires browser impl)

<masinter> SVG requires browser or browser plugin implementation

<Zakim> ChrisWilson, you wanted to say I think the problem is in how "legitimate" we would be making the extensions done by plugins _to_the_core_language.

sam: the language may not need to anoint RDFa, but probably does SVG.

<shepazu> [RDFa doesn't *require* any extra browser support beyond putting them in the DOM, but it could benefit from it (if, for example, it takes the cue that an address is an address, and provides a map option, etc.)]

sam: anything else on this before we move on?
... last I'd heard, it was Rob Sayre's intent to include summary and profile

<MikeSmith> shepazu, have not some suggestions about RDFa in text/html been predicated on having some form of namespace support in text/html parsers

<shepazu> MikeSmith: that's true

<shepazu> good point

sam: chris, care to say anything in advance of your one due next week on HTML extensibility?

chris: just that I agree with your general sentiment that language extensibility is a good thing (based on our experience in IE), but core platform features should be in the language.

sam: with that, let's adjourn

<smedero> rrsagent: draft minutes

<pimpbot> Title: HTML Weekly Teleconference -- 09 Apr 2009 (at www.w3.org)

<Philip> (SVG doesn't necessarily require browser implementation - you could emulate much of it with script and <canvas> (which people have done already, to some extent), or lots and lots of coloured <div>s)

<shepazu> Philip: or VML, which seems more common

<shepazu> that is, SVG rendered in VML

<Philip> Indeed

<Philip> so I still don't see a clear distinction between that and e.g. RDFa which can be emulated with scripts and current HTML parsers creating attributes with localNames like "xmlns:dc" and so on

<pimpbot> Title: HTML Weekly Teleconference -- 09 Apr 2009 (at www.w3.org)

<pimpbot> Title: HTML Weekly Teleconference -- 09 Apr 2009 (at www.w3.org)