Re: Prism WPD plugin ‹ Telling HTML and XML (SVG, MathML etc) apart

Even cooler! Thanks, Lea! J


Sent from my "Smartphone" -- go figure...


----- Reply message -----
From: "Lea Verou" <lea@w3.org>
To: "Julee Burdekin" <jburdeki@adobe.com>
Cc: "public-webplatform@w3.org" <public-webplatform@w3.org>, "Doug Schepers" <schepers@w3.org>
Subject: Prism WPD plugin ‹ Telling HTML and XML (SVG, MathML etc) apart
Date: Sat, May 18, 2013 6:46 AM



Hi Julee,

See inline answers.

On May 13, 2013, at 21:50, Julee Burdekin <jburdeki@adobe.com<mailto:jburdeki@adobe.com>> wrote:

Lea:

This is sooo cool. But I'm not sure what the offering is and what the interface is. Do I have this right? prismjs is syntax highlighting with a keyword linker plugin?
Exactly.

Will the users of code.webplatform.org<http://code.webplatform.org> have do anything or is the keyword linker plugin something you plug in to code.webplatform.org<http://code.webplatform.org>?
We will plug it into code.webplatform.org<http://code.webplatform.org> as well, but the main idea is something much bigger. Something that won't just be used in WPD Code or WPD code examples, but also in other websites that use Prism (and there are many, even big ones like Smashing Magazine or A List Apart) to promote WPD by adding value for their users. Win-win :)

Cheers,
Lea

Thanks!

Julee
----------------------------
julee@adobe.com<mailto:julee@adobe.com>
@adobejulee

From: Lea Verou <lea@w3.org<mailto:lea@w3.org>>
Date: Saturday, May 11, 2013 3:24 PM
To: "public-webplatform@w3.org<mailto:public-webplatform@w3.org>" <public-webplatform@w3.org<mailto:public-webplatform@w3.org>>
Cc: Doug Schepers <schepers@w3.org<mailto:schepers@w3.org>>
Subject: Re: Prism WPD plugin — Telling HTML and XML (SVG, MathML etc) apart
Resent-From: <public-webplatform@w3.org<mailto:public-webplatform@w3.org>>
Resent-Date: Saturday, May 11, 2013 3:24 PM

Here’s a first alpha version: http://prismjs.com/plugins/wpd/

It’s still unpublished in the plugin directory, as I wanted to get some feedback first. The tokens should be properly linked. Their styling is too obvious at this point, to spot potential mistakes. Before publishing, I will make the underline on hover only.

Things that are linked:

CSS
- properties
- atrules
- pseudo-classes
- pseudo-elements

Markup
- tags
- attributes

What else should I add? Please note that it should be easy to programmatically detect, e.g. CSS values like <length> would require lots of special casing.

Distinguishing between markup types proved out to be even harder than the solution I outlined in the previous message: Several (not few) elements did not correspond to specific interfaces in some browser, so I had to cache them in the script. Also, no browser seems to provide interface names for MathML elements, so I hacked around it by caching the HTML+SVG elements that start with "m" and having all others considered MathML.

Any feedback is very welcome.

Lea Verou
W3C developer relations
http://w3.org/people/all#lea ? http://lea.verou.me<http://lea.verou.me/> ? @leaverou






On May 10, 2013, at 22:12, Lea Verou <lea@w3.org<mailto:lea@w3.org>> wrote:

The problem
=============
As you might know, I’m writing a Prism [1] plugin that converts some tokens [3] into links to WPD documentation, both for our use and for developers in general, to promote WPD. A conundrum I ran into was how to do that for HTML and XML languages such as SVG and MathML. Prism currently uses the same language definition for both HTML and XML variants ("markup"), so it was hard for the plugin to decide where to link tokens found in "markup" contexts.

Solution #1
===========
We chatted about this with Doug last week and we decided on using the WPD API to fetch a list of tags for HTML, SVG and MathML, so that Prism could use those to decide where those tokens [3] would link to. However, when I investigated this idea (thanks fr0zenice for helping with the API!), I encountered a number of issues. Since plugins hook into Prism’s main code, there is no way for a plugin to delay Prism execution (e.g. until an async request finishes). Therefore, the API requests would need to happen synchronously. This is a bad practice and could cause significant delays, making the plugin less appealing to authors. So, this solution is not feasible after all.

Note that we could always make an extended version of the plugin in the future, which makes API requests when somebody hovers over these tokens showing a tooltip or something, which would fetch the API info just-in-time instead of when the page loads.

Solution #2
===========
The idea I’m probably going with (unless somebody has something better to suggest, which is why I'm writing this email) is to defer element recognition to the browser. Every known element (with very few exceptions, which could be special cased) corresponds to a specific interface, e.g. HTMLInputElement or SVGCircleElement. There is a way to get this interface name through JavaScript [2]. Unknown elements on the other hand resolve to different interface names, such as HTMLUnknownElement or HTMLElement or Element, depending on the browser. I’ve verified this is true for both Trident (IE10), WebKit and Gecko.
The main issue I see with this solution is that elements that are not supported by the current browser would not be linked. That's unfortunate, but I don't think it's a blocker.

Hope it all makes sense, I tried to describe it in as much detail as possible. Any feedback and/or advice is welcome!

[1]: http://prismjs.com<http://prismjs.com/>
[2]: e.g. try document.createElementNS('http://www.w3.org/2000/svg', 'circle').toString()
[3] tokens in this context are the parts of the code that get highlighted, e.g. "tag", "attribute", "property" etc.

Lea Verou
W3C developer relations
http://w3.org/people/all#lea ? http://lea.verou.me<http://lea.verou.me/> ? @leaverou