On Sep 2, 2010, at 11:24 AM, Yuras Shumovich wrote:
> Is it possible to switch back from frame version to non frame version?
> The "Frames" button disappears in frame mode...
I usually just right-click on the main page and select "Open frame in new
window...". I could have made the "Frames" but
On 6 September 2010 17:11, Mark Lentczner wrote:
> On Sep 6, 2010, at 2:40 AM, Henning Thielemann wrote:
>> ... focusing on a small set of assumed popular browsers ...
>
> I didn't want to assume either. I ran a survey of the Haskell community and
> got over a 150 responses.
> On Sep 6, 2010, at
On Sep 6, 2010, at 2:40 AM, Henning Thielemann wrote:
> ... focusing on a small set of assumed popular browsers ...
I didn't want to assume either. I ran a survey of the Haskell community and got
over a 150 responses. The multiple choice browser question yielded:
Firefox: 59%
Chr
Mark Lentczner schrieb:
> The choice to generate Haddock output as XHTML 1.0 Transitional and Frames,
> stored into files with an extension of .html, and that would likely be served
> as text/html, was mine and I did so with review of current best practices.
> The output Haddock now generates r
On Sat, Sep 4, 2010 at 14:46, Jeremy Shaw wrote:
> So the choices are:
>
> 1. only focus on getting the xhtml 1.0 served as application/xml
> working correctly, and ie users get nothing..
>
> 2. create xhtml 1.0 that would work correctly if served as
> application/xml, but serve it as text/html,
On Sat, Sep 4, 2010 at 8:47 PM, Brandon S Allbery KF8NH
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 9/4/10 21:27 , Jeremy Shaw wrote:
>> Here is why I am dubious. Browsers that support html and xhtml have
>> two different code paths for rending html vs xhtml. The *only* way to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/4/10 21:27 , Jeremy Shaw wrote:
> Here is why I am dubious. Browsers that support html and xhtml have
> two different code paths for rending html vs xhtml. The *only* way to
> select which code path is taken is by specifying the mime-type when
> y
On Thu, Sep 2, 2010 at 11:14 PM, Mark Lentczner wrote:
> I am well aware of the differences between HTML and XHTML.
>
> I choose to switch Haddock's output from HTML to XHTML mostly because I have
> found the consistency of rendering cross-browser to be greater and easier to
> achieve with XHTML
On 10-09-04 05:46 PM, Jeremy Shaw wrote:
Mark suggested that it was easier to achieve multi-browser
compatibility using xhtml instead of html, but I am quite certain he
is mistaken. There are really three different rendering modes found in
browsers:
1. standards mode
2. quirks mode
3. xhtm
We all seem to understand that there are a complex of issues surrounding the
HTML and XHTML dialects, doc types, MIME Types, and file extensions. It is a
tangle of intentions and compatibility issues, and one where experts and
standards writers admit to practical compromises, which at times are
On 10-09-04 01:31 AM, John Millikin wrote:
It's not correct. Here's the exact same XHTML document (verify by
viewing the source), served with different mimetypes:
http://ianen.org/temp/inline-svg.html
http://ianen.org/temp/inline-svg.xhtml
This relies on xhtml+svg. While it is in the xhtml fam
On Sat, Sep 4, 2010 at 12:19 PM, David Menendez wrote:
> HTML and XHTML are not encodings of anything. They are markup
> languages defined using SGML and the XML subset of SGML. There are
> multiple HTML definitions of varying popularity, and the fact that we
> can pass some XHTML documents to a w
On Sat, Sep 4, 2010 at 11:07 AM, John Millikin wrote:
> On Fri, Sep 3, 2010 at 23:02, David Menendez wrote:
>> Yes, using foreign namespaces is one of the things recommended against
>> when serving XHTML as text/html. This says nothing about documents
>> following the recommendations in Appendix
On Fri, Sep 3, 2010 at 23:02, David Menendez wrote:
> Yes, using foreign namespaces is one of the things recommended against
> when serving XHTML as text/html. This says nothing about documents
> following the recommendations in Appendix C.
>
>> I'm not debating that it's *possible* to serve HTML
On Sat, Sep 4, 2010 at 1:31 AM, John Millikin wrote:
> On Fri, Sep 3, 2010 at 20:39, Albert Y. C. Lai wrote:
>> In theory, what does file extension matter? Media type is the dictator. The
>> normative Section 5.1 permits the choice of application/xhtml+xml or
>> text/html. While the latter entail
On Fri, Sep 3, 2010 at 20:39, Albert Y. C. Lai wrote:
> In theory, what does file extension matter? Media type is the dictator. The
> normative Section 5.1 permits the choice of application/xhtml+xml or
> text/html. While the latter entails extra requirements in the informative
> Appendix C, as fa
On 9/2/10 9:57 PM, John Millikin wrote:
Is there any particular reason you're using XHTML instead of HTML?
You're using a transitional doctype, invalid IDs, and the .html file
extension -- in short, HTML with an incorrect doctype. The markup
doesn't even validate.
Because HTML is evil? Though,
On Fri, Sep 3, 2010 at 12:40 AM, John Millikin wrote:
>
> Haddock is generating files with an .html extension, which causes
> webservers to serve it using "text/html", the incorrect MIME-type.
Secton 5.1 of the XHTML recommendation states: "XHTML Documents which
follow the guidelines set forth in
On 10-09-02 09:57 PM, John Millikin wrote:
Is there any particular reason you're using XHTML instead of HTML?
You're using a transitional doctype, invalid IDs, and the .html file
extension -- in short, HTML with an incorrect doctype. The markup
doesn't even validate.
[...]
XHTML is supported by
On Thu, Sep 2, 2010 at 21:14, Mark Lentczner wrote:
> I choose to switch Haddock's output from HTML to XHTML mostly because I have
> found the consistency of rendering cross-browser to be greater and easier to
> achieve with XHTML. I'm not alone in this opinion: Many well respected web
> design
I am well aware of the differences between HTML and XHTML.
I choose to switch Haddock's output from HTML to XHTML mostly because I have
found the consistency of rendering cross-browser to be greater and easier to
achieve with XHTML. I'm not alone in this opinion: Many well respected web
design
On 3 September 2010 11:57, John Millikin wrote:
> Is there any particular reason you're using XHTML instead of HTML?
>
> [snip]
>
> XHTML is supported by most modern browsers (Firefox, Chrome,
> Safari, Opera, etc), but not by any currently released version of
> Internet Explorer.
Sounds like a g
Is there any particular reason you're using XHTML instead of HTML?
You're using a transitional doctype, invalid IDs, and the .html file
extension -- in short, HTML with an incorrect doctype. The markup
doesn't even validate.
In case you're not aware, HTML and XHTML are separate file formats.
HTML
2010/9/2 Daniel Peebles :
> Mmm, delicious! Thanks to all involved! Any idea how long it'll take for
> this to make it to hackage and regenerate all the documentation up there?
> It'd be wonderful to do the same to the GHC documentation too.
I don't actually know yet if it's possible to regenerate
2010/9/2 Henk-Jan van Tuyl :
> On Thu, 02 Sep 2010 14:00:56 +0200, David Waern
> wrote:
>
>>
>> -- Haddock 2.8.0
>>
>>
>> A new version of Haddock, the Haskell documentation tool, is out!
>>
>
> It doesn't in
On Thu, 02 Sep 2010 14:00:56 +0200, David Waern
wrote:
-- Haddock 2.8.0
A new version of Haddock, the Haskell documentation tool, is out!
It doesn't install on Windows + MinGW:
cabal install --glob
2010/9/2 Mark Lentczner :
> On Sep 2, 2010, at 5:00 AM, David Waern wrote:
> If you'd like to see the new look in action, I've generated some pages for a
> few packages here:
> http://www.ozonehouse.com/mark/snap-xhtml/
Is it possible to switch back from frame version to non frame version?
On Sep 2, 2010, at 5:00 AM, David Waern wrote:
> -- Haddock 2.8.0
> A new version of Haddock, the Haskell documentation tool, is out!
>
> The biggest news this time is that we have a shiny new XHTML backend, created
> by Mark Lentczner, ... Included is a new default CSS theme created by Thomas
>
-- Haddock 2.8.0
A new version of Haddock, the Haskell documentation tool, is out!
The biggest news this time is that we have a shiny new XHTML backend, created
by Mark Lentczner, which outputs semantically
29 matches
Mail list logo
