michelf
Repos
16
Followers
145

Events

issue comment
Better Footnote title attributes?

Personally, I think we could cheat a bit more. Something like this:

list($title, $tail) = preg_split('{</p\s*>\s*}i', $title, 2); // split at </p>
$truncated = $tail != '';
$title = preg_replace('{<img\b[^<]\balt\s*=\s*(?:"([^"]*")|(\'([^\']*\')|(\S*)\b)[^<]*>}i', '\1'\2\3, $title); // img -> alt text
$title = preg_replace('{\s+}', ' ', $title); // normalize whitespace
$title = trim($title); // remove leading & trailing whitespace
$title = preg_replace('{<br\s*/?>}i', '\n', $title); // br -> \n
$title = strip_tags($title);
$before_truncation = $title;
$title = preg_replace('{^.{0,100}+?\b}', '', $title); // cut after 100 characters, but continue for last word.
if ($truncated || $before_truncation != $title) {
   $title .= '…'; // add ellipsis after truncation
}

There's some situations where the img will be parsed incorrectly (if you include unescaped > in quoted attributes (other than the alt itself). But otherwise it should work... in theory. I didn't test it at all, feel free if you want to.

Created at 3 weeks ago
issue comment
Better Footnote title attributes?

I think truncating it if too long makes this idea reasonable. It should probably truncate at the first end of paragraph </p> and some other tags too (<table>, <blockquote>…). It'd be nice to replace images with the alt text. And spacing is interpreted differently inside title="" than in HTML, so it should probably be somehow normalized (collapsing double-spaces and newlines, then replacing <br/> with actual newlines).

Sorry if this seems a lot of work. Maybe it's not all needed.

I'm not sure if this tooltip should be the default, but at least it should be possible to enable or disable it.

Created at 3 weeks ago
issue comment
Better Footnote title attributes?

How do you propose to handle footnotes like this one[^1].

[^1]: Footnotes are often one line of text, but this line of text can contain formatting such as code, emphasis, links, and images such as this one. Actually, it wouldn't surprise me to find that links are pretty common since footnotes are often used for references.

They can also go quite long with paragraphs and other block-level elements such as:

| tables | tables |
| ------ | ------ |
| rows   | rows   |

> blockquotes

    code blocks

- lists
- and more lists

So we need a strategy to deal with this. I don't think `strip_tags` is good enough.

                            
Created at 3 weeks ago
pull request closed
Bump the version to 1.10.0

https://github.com/michelf/php-markdown/pull/382#issuecomment-1255149978

Created at 2 months ago
issue comment
Bump the version to 1.10.0

I made a couple more changes in #385 and ended up tagging the result as 2.0.0.

Thank you for your help.

Created at 2 months ago
michelf create tag 2.0.0
Created at 2 months ago
pull request closed
Lib 2.x

Added type declarations to MarkdownInterface and other cleanups for making 2.0.0 ready.

Created at 2 months ago

Updating Readme and copyright for 1.9.1.

Merge remote-tracking branch 'github/lib' into lib-1.x

Preparing release notes for 1.10.0.

Adding a couple of missing type annotations.

Updated copyright year.

Updated MarkdownInteface to use type declarations.

Bumping version number to 2.0.0.

Fixing copyright year for License.md.

Mention of the exclusion of developer files in composer package in version history.

Created at 2 months ago

Fixing copyright year for License.md.

Mention of the exclusion of developer files in composer package in version history.

Created at 2 months ago
pull request closed
v1.10.0

Not entirely sure yet if this should be 2.0.0 or 1.10.0, but I'm leaning for 1.10.0 because it seems very unlikely type annotations would break any code and the new requirement for PHP 7.4 should be handled fine by composer.

Created at 2 months ago
issue comment
v1.10.0

Abandoned, going to use 2.0.0 after additional type declarations in MarkdownInterface. See #385

Created at 2 months ago
pull request opened
Lib 2.x

Added type declarations to MarkdownInterface and other cleanups for making 2.0.0 ready.

Created at 2 months ago
Created at 2 months ago
create branch
michelf create branch lib-2.x
Created at 2 months ago
pull request opened
v1.10.0

Not entirely sure yet if this should be 2.0.0 or 1.10.0, but I'm leaning for 1.10.0 because it seems very unlikely type annotations would break any code and the new requirement for PHP 7.4 should be handled fine by composer.

Created at 2 months ago

bump php version and phpunit

allow php7.2+

allow php7.3+

bump minimum to php 7.4

bump to php 7.4

Merge pull request #358 from tacman/dev-2.0

Bump to php7.4

type arrays for class and subclass

remove rector

declare types in php rather than annotations

Merge branch 'michelf:lib' into feature-typehints

Merge branch 'tacman-feature-typehints' into lib

add github actions

Merge branch 'michelf:lib' into lib

add more ci

drop 7.3

drop codestyle check

replace hard-coded links to badges

always exists, no need to check for isset()

remove badge link

fix some errors reported by phpstan

Created at 2 months ago
issue comment
Remove type attributes

I think per the versioning policy we should keep the types attributes for protected properties.

For the public ones, this is more nuanced, and I'm still trying to wrap my head around it. Strictly speaking this is a breaking change for users using declare(strict_types=1). Even without this mode, it could in some case create errors where a user of the library would be setting a string property with an array value, or the reverse (which might or might not create an error down the line depending on the parsed input). In practice I doubt very much it'd affect anyone. It all seems very unlikely to me, but I don't really know. Any comment on that?

In any case I don't think the downsides of making it a major version (slowing down adoption, prompting people to read a changelog saying "we added type attributes" before deciding to allow a 2.0.0 version) is worth it.

Created at 2 months ago
issue comment
preg_split returning false will cause TypeError on invalid countable in PHP 8

Oh, didn't think about that actually. I was planning on deciding between 1.9.2 and 1.10.0 after looking at the changes... but changing the major version just for type annotations makes me rethink whether those type annotations are really worth the trouble. 🤔

Created at 2 months ago
issue comment
preg_split returning false will cause TypeError on invalid countable in PHP 8

I guess what remains would be to pick a version number, and write the change log in Readme.md.

I should be able to do that by tomorrow.

Created at 2 months ago
issue comment
preg_split returning false will cause TypeError on invalid countable in PHP 8

Thank you.

Created at 2 months ago

preg_split returning false will cause TypeError on invalid countable in PHP 8

Merge pull request #379 from sanmai/patch-1

preg_split returning false will cause TypeError on invalid countable in PHP 8

Created at 2 months ago
pull request closed
preg_split returning false will cause TypeError on invalid countable in PHP 8
Created at 2 months ago
issue comment
Sample use?

The Readme.php file is meant as a simple example.

Created at 2 months ago